-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DPE-2119] fix issues and tests when reusing storage #272
Conversation
…hen reusing de-attached storage)
…ge instead of rootfs
…down not all shards are assigned
…ter_app_removal` as it currently does not work
This PR updates the installed snap to the fixed version which can install on existing storage and does not overwrite the data in snap_common. Other content of this PR: The integration test
The test case |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks René! Could we add a test which does:
- stopping continuous writes
- scale-down to 0 units (while keeping storage around)
- scale-up to N units with storage attach
- check if the continuous writes data has been indeed been kept and is usable
… this ensures enough data gets written by then
…can still be run in case of hooks failure
… in re-attached storage is persistent
…nd scaling up again with re-attached storage as this currently does not work in general
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Let's give this logic a try with the integration tests and see how it goes.
…al, adjust the logic to destroy the application due to #243
…uster with re-attached storage
…hen reusing de-attached storage)
…ge instead of rootfs
…rm_node_lock index is not available
…index (will be tracked in #321)
- block until removed test_storage.py: remove the application completely, blocking until it's removed; use wait_until from helpers instead of from ops_test to be more secure on application availability
…curity index (is already present in main)
…-attach-existing-storage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @reneradoi I had a similar issue as yours, where there were units initially available for shards but they were still hanging as "UNASSIGNED". Although that was not about the lock itself, I think we can troubleshoot your problem here the same way.
I've added this logic here to give me more logs. You have to tweak the "explain" API to target the charm lock itself.
…llback to peer databag lock if it's 2 or less units
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. My only remark is that we need to dig more into what is causing the 503.
On a separate PR, we should log 503 errors and its explanation, as follows:
GET _cluster/allocation/explain
{
"index": ".charm-node-lock",
}
Yes that's true, I'll add another issue or draft PR, will think about it. |
Issue
When attaching an existing storage to a new unit, 2 issues happen:
Solution
Integration Testing
Tests for attaching existing storage can be found in integration/ha/test_storage.py. There are now three test cases:
Other Issues
As part of this PR, another issue is addressed: #306. It is resolved with this commit: 19f843c